home *** CD-ROM | disk | FTP | other *** search
/ Halting the Hacker - A P…uide to Computer Security / Halting the Hacker - A Practical Guide to Computer Security.iso / rfc / rfc1554.txt < prev    next >
Text File  |  1997-04-01  |  11KB  |  339 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                            M. Ohta
  8. Request for Comments: 1554                 Tokyo Institute of Technology
  9. Category: Informational                                         K. Handa
  10.                                                                      ETL
  11.                                                            December 1993
  12.  
  13.  
  14.           ISO-2022-JP-2: Multilingual Extension of ISO-2022-JP
  15.  
  16. Status of this Memo
  17.  
  18.    This memo provides information for the Internet community.  This memo
  19.    does not specify an Internet standard of any kind.  Distribution of
  20.    this memo is unlimited.
  21.  
  22. Introduction
  23.  
  24.    This memo describes a text encoding scheme: "ISO-2022-JP-2", which is
  25.    used experimentally for electronic mail [RFC822] and network news
  26.    [RFC1036] messages in several Japanese networks.  The encoding is a
  27.    multilingual extension of "ISO-2022-JP", the existing encoding for
  28.    Japanese [2022JP].  The encoding is supported by an Emacs based
  29.    multilingual text editor: MULE [MULE].
  30.  
  31.    The name, "ISO-2022-JP-2", is intended to be used in the "charset"
  32.    parameter field of MIME headers (see [MIME1] and [MIME2]).
  33.  
  34. Description
  35.  
  36.    The text with "ISO-2022-JP-2" starts in ASCII [ASCII], and switches
  37.    to other character sets of ISO 2022 [ISO2022] through limited
  38.    combinations of escape sequences.  All the characters are encoded
  39.    with 7 bits only.
  40.  
  41.    At the beginning of text, the existence of an announcer sequence:
  42.    "ESC 2/0 4/1 ESC 2/0 4/6 ESC 2/0 5/10" is (though omitted) assumed.
  43.    Thus, characters of 94 character sets are designated to G0 and
  44.    invoked as GL.  C1 control characters are represented with 7 bits.
  45.    Characters of 96 character sets are designated to G2 and invoked with
  46.    SS2 (single shift two, "ESC 4/14" or "ESC N").
  47.  
  48.    For example, the escape sequence "ESC 2/4 2/8 4/3" or "ESC $ ( C"
  49.    indicates that the bytes following the escape sequence are Korean KSC
  50.    characters, which are encoded in two bytes each.  The escape sequence
  51.    "ESC 2/14 4/1" or "ESC . A" indicates that ISO 8859-1 is designated
  52.    to G2. After the designation, the single shifted sequence "ESC 4/14
  53.    4/1" or "ESC N A" is interpreted to represent a character "A with
  54.    acute".
  55.  
  56.  
  57.  
  58. Ohta & Handa                                                    [Page 1]
  59.  
  60. RFC 1554         Multilingual Extension of ISO-2022-JP     December 1993
  61.  
  62.  
  63.    The following table gives the escape sequences and the character sets
  64.    used in "ISO-2022-JP-2" messages. The reg# is the registration number
  65.    in ISO's registry [ISOREG].
  66.  
  67.                               94 character sets
  68.       reg#  character set      ESC sequence                designated to
  69.       ------------------------------------------------------------------
  70.       6     ASCII              ESC 2/8 4/2      ESC ( B    G0
  71.       42    JIS X 0208-1978    ESC 2/4 4/0      ESC $ @    G0
  72.       87    JIS X 0208-1983    ESC 2/4 4/2      ESC $ B    G0
  73.       14    JIS X 0201-Roman   ESC 2/8 4/10     ESC ( J    G0
  74.       58    GB2312-1980        ESC 2/4 4/1      ESC $ A    G0
  75.       149   KSC5601-1987       ESC 2/4 2/8 4/3  ESC $ ( C  G0
  76.       159   JIS X 0212-1990    ESC 2/4 2/8 4/4  ESC $ ( D  G0
  77.  
  78.                               96 character sets
  79.       reg#  character set      ESC sequence                designated to
  80.       ------------------------------------------------------------------
  81.       100   ISO8859-1          ESC 2/14 4/1     ESC . A    G2
  82.       126   ISO8859-7(Greek)   ESC 2/14 4/6     ESC . F    G2
  83.  
  84.    For further information about the character sets and the escape
  85.    sequences, see [ISO2022] and [ISOREG].
  86.  
  87.    If there is any G0 designation in text, there must be a switch to
  88.    ASCII or to JIS X 0201-Roman before a space character (but not
  89.    necessarily before "ESC 4/14 2/0" or "ESC N ' '") or control
  90.    characters such as tab or CRLF.  This means that the next line starts
  91.    in the character set that was switched to before the end of the
  92.    previous line.  Though the designation to JIS X 0201-Roman is allowed
  93.    for backward compatibility to "ISO-2022-JP", its use is discouraged.
  94.    Applications such as pagers and editors which randomly seek within a
  95.    text file encoded with "ISO-2022-JP-2" may assume that all the lines
  96.    begin with ASCII, not with JIS X 0201-Roman.
  97.  
  98.    At the beginning of a line, information on G2 designation of the
  99.    previous line is cleared.  New designation must be given before a
  100.    character in 96 character sets is used in the line.
  101.  
  102.    The text must end in ASCII designated to G0.
  103.  
  104.    As the "ISO-2022-JP", and thus, "ISO-2022-JP-2", is designed to
  105.    represent English and modern Japanese, left-to-right directionality
  106.    is assumed if the text is displayed horizontally.
  107.  
  108.    Users of "ISO-2022-JP-2" must be aware that some common transport
  109.    such as old Bnews can not relay a 7-bit value 7/15 (decimal 127),
  110.    which is used to encode, say, "y with diaeresis" of ISO 8859-1.
  111.  
  112.  
  113.  
  114. Ohta & Handa                                                    [Page 2]
  115.  
  116. RFC 1554         Multilingual Extension of ISO-2022-JP     December 1993
  117.  
  118.  
  119.    Other restrictions are given in the Formal Syntax section below.
  120.  
  121. Formal Syntax
  122.  
  123.    The notational conventions used here are identical to those used in
  124.    STD 11, RFC 822 [RFC822].
  125.  
  126.    The * (asterisk) convention is as follows:
  127.  
  128.       l*m something
  129.  
  130.    meaning at least l and at most m somethings, with l and m taking
  131.    default values of 0 and infinity, respectively.
  132.  
  133.    message             = headers 1*(CRLF text)
  134.                                           ; see also [MIME1] "body-part"
  135.                                           ; note: must end in ASCII
  136.  
  137.    text                = *(single-byte-char /
  138.                            g2-desig-seq /
  139.                            single-shift-char)
  140.                           [*segment
  141.                            reset-seq
  142.                            *(single-byte-char /
  143.                              g2-desig-seq /
  144.                              single-shift-char ) ]
  145.                                           ; note: g2-desig-seq must
  146.                                           ; precede single-shift-char
  147.  
  148.    headers             = <see [RFC822] "fields" and [MIME1] "body-part">
  149.  
  150.    segment             = single-byte-segment / double-byte-segment
  151.  
  152.    single-byte-segment = single-byte-seq
  153.                          *(single-byte-char /
  154.                            g2-desig-seq /
  155.                            single-shift-char )
  156.  
  157.    double-byte-segment = double-byte-seq
  158.                          *((one-of-94 one-of-94) /
  159.                            g2-desig-seq /
  160.                            single-shift-char )
  161.  
  162.    reset-seq           = ESC "(" ( "B" / "J" )
  163.  
  164.    single-byte-seq     = ESC "(" ( "B" / "J" )
  165.  
  166.    double-byte-seq     = (ESC "$" ( "@" / "A" / "B" )) /
  167.  
  168.  
  169.  
  170. Ohta & Handa                                                    [Page 3]
  171.  
  172. RFC 1554         Multilingual Extension of ISO-2022-JP     December 1993
  173.  
  174.  
  175.                          (ESC "$" "(" ( "C" / "D" ))
  176.  
  177.    g2-desig-seq        = ESC "." ( "A" / "F" )
  178.  
  179.    single-shift-seq    = ESC "N"
  180.  
  181.    single-shift-char   = single-shift-seq one-of-96
  182.  
  183.    CRLF                = CR LF
  184.  
  185.                                                     ; ( Octal, Decimal.)
  186.  
  187.    ESC                 = <ISO 2022 ESC, escape>     ; (    33,      27.)
  188.  
  189.    SI                  = <ISO 2022 SI, shift-in>    ; (    17,      15.)
  190.  
  191.    SO                  = <ISO 2022 SO, shift-out>   ; (    16,      14.)
  192.  
  193.    CR                  = <ASCII CR, carriage return>; (    15,      13.)
  194.  
  195.    LF                  = <ASCII LF, linefeed>       ; (    12,      10.)
  196.  
  197.    one-of-94           = <any one of 94 values>     ; (41-176, 33.-126.)
  198.  
  199.    one-of-96           = <any one of 96 values>     ; (40-177, 32.-127.)
  200.  
  201.    7BIT                = <any 7-bit value>          ; ( 0-177,  0.-127.)
  202.  
  203.    single-byte-char    = <any 7BIT, including bare CR & bare LF, but NOT
  204.                           including CRLF, and not including ESC, SI, SO>
  205.  
  206. MIME Considerations
  207.  
  208.    The name given to the character encoding is "ISO-2022-JP-2". This
  209.    name is intended to be used in MIME messages as follows:
  210.  
  211.       Content-Type: text/plain; charset=iso-2022-jp-2
  212.  
  213.    The "ISO-2022-JP-2" encoding is already in 7-bit form, so it is not
  214.    necessary to use a Content-Transfer-Encoding header. It should be
  215.    noted that applying the Base64 or Quoted-Printable encoding will
  216.    render the message unreadable in non-MIME-compliant software.
  217.  
  218.    "ISO-2022-JP-2" may also be used in MIME headers.  Both "B" and "Q"
  219.    encoding could be useful with "ISO-2022-JP-2" text.
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Ohta & Handa                                                    [Page 4]
  227.  
  228. RFC 1554         Multilingual Extension of ISO-2022-JP     December 1993
  229.  
  230.  
  231. References
  232.  
  233.    [ASCII] American National Standards Institute, "Coded character set
  234.            -- 7-bit American national standard code for information
  235.            interchange", ANSI X3.4-1986.
  236.  
  237.  
  238.    [ISO2022] International Organization for Standardization (ISO),
  239.              "Information processing -- ISO 7-bit and 8-bit coded
  240.              character sets -- Code extension techniques",
  241.              International Standard, Ref. No. ISO 2022-1986 (E).
  242.  
  243.    [ISOREG] International Organization for Standardization (ISO),
  244.             "International Register of Coded Character Sets To Be Used
  245.             With Escape Sequences".
  246.  
  247.    [MIME1] Borenstein, N., and N. Freed, "MIME  (Multipurpose Internet
  248.            Mail Extensions) Part One: Mechanisms for Specifying and
  249.            Describing the Format of Internet Message Bodies", RFC 1521,
  250.            September 1993.
  251.  
  252.    [MIME2] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
  253.            Two: Message Header Extensions for Non-ASCII Text", RFC 1522,
  254.            September 1993.
  255.  
  256.    [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text
  257.             Messages", STD 11, RFC 1522, UDEL, August 1982.
  258.  
  259.    [RFC1036] Horton M., and R. Adams, "Standard for Interchange of
  260.              USENET Messages", RFC 1036, AT&T Bell Laboratories, Center
  261.              for Seismic Studies, December 1987.
  262.  
  263.    [2022JP] Murai, J., Crispin, M., and E. van der Poel, "Japanese
  264.             Character Encoding for Internet Messages", RFC 1468, June
  265.             1993.
  266.  
  267.    [MULE] Nishikimi, M., Handa, K., and S. Tomura, "Mule: MULtilingual
  268.           Enhancement to GNU Emacs", Proc. of INET'93, August, 1993.
  269.  
  270. Acknowledgements
  271.  
  272.    This memo is the result of discussion between various people in a
  273.    news group: fj.kanji and is reviewed by a mailing list: jp-msg
  274.    @iij.ad.jp.  The Authors wish to thank in particular Prof. Eiichi
  275.    Wada for his suggestions based on profound knowledge in ISO 2022 and
  276.    related standards.
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Ohta & Handa                                                    [Page 5]
  283.  
  284. RFC 1554         Multilingual Extension of ISO-2022-JP     December 1993
  285.  
  286.  
  287. Security Considerations
  288.  
  289.    Security issues are not discussed in this memo.
  290.  
  291. Authors' Addresses
  292.  
  293.    Masataka Ohta
  294.    Tokyo Institute of Technology
  295.    2-12-1, O-okayama, Meguro-ku,
  296.    Tokyo 152, JAPAN
  297.  
  298.    Phone: +81-3-5499-7084
  299.    Fax: +81-3-3729-1940
  300.    EMail: mohta@cc.titech.ac.jp
  301.  
  302.  
  303.    Ken'ichi Handa
  304.    Electrotechnical Laboratory
  305.    Umezono 1-1-4, Tsukuba,
  306.    Ibaraki 305, JAPAN
  307.  
  308.    Phone: +81-298-58-5916
  309.    Fax: +81-298-58-5918
  310.    EMail: handa@etl.go.jp
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Ohta & Handa                                                    [Page 6]
  339.